十多年来，人们很难从他们的数据中获得可操作的见解这一事实一直被归咎于数据的规模。“你的数据对于系统来说太大了，”这是诊断，而解决办法是购买一些能够处理大规模数据的新奇技术。当然，在大数据任务组购买了所有新工具并从遗留系统迁移之后，人们发现他们仍然无法理解他们的数据。他们也可能已经注意到，如果他们真的注意的话，数据大小根本不是问题所在。

2023 年的世界看起来与大数据警钟开始响起时不同。所预测的数据灾难并没有发生。数据量可能略微变大了，但硬件却以更快的速度变大了。供应商仍在推动他们的扩展能力，但从业者开始怀疑这与他们现实世界的问题有何关系。

关于这篇文章 这篇文章将证明大数据时代已经结束。它运行良好，但现在我们可以不再担心数据大小，而是专注于我们将如何使用它来做出更好的决策。我会展示一些图表；这些都是凭记忆手绘的。如果我确实可以访问确切的数字，我将无法分享它们。但重要的部分是趋势，而不是确切的值。

图表背后的数据来自分析查询日志、交易事后分析、基准测试结果（已发布和未发布）、客户支持票、客户对话、服务日志和已发布的博客文章，以及一些直觉。

大数据开场

在过去的 10 年里，每一个大数据产品的每一个推销平台都是从一张看起来像这样的幻灯片开始的：

我们在 Google 多年来一直使用这张幻灯片的一个版本。当我搬到 SingleStore 时，他们使用的是具有相同图表的自己的版本。我见过其他几家供应商也有类似的东西。这是“恐慌”幻灯片。大数据来了！你需要买我的东西！

消息是处理数据的旧方法行不通了。数据生成的加速将使过去的数据系统陷入泥潭，任何接受新想法的人都能够超越他们的竞争对手。

当然，仅仅因为生成的数据量在增加并不意味着它成为每个人的问题；数据分布不均。大多数应用程序不需要处理大量数据。这导致了具有传统架构的数据管理系统的复兴；SQLite、Postgres、MySQL 都在强劲增长，而“NoSQL”甚至“NewSQL”系统则停滞不前。

MongoDB 是排名最高的 NoSQL 或其他横向扩展数据库，虽然它多年来有不错的增长，但最近一直在小幅下降，并且与 MySQL 或 Postgres 这两个绝对单一的数据库相比并没有真正取得太大进展 . 如果大数据真的接管了一切，你会期望在这些年后看到一些不同的东西。

当然，在分析系统中情况看起来有所不同，但在 OLAP 中，您会看到从内部部署到云的巨大转变，并且实际上没有任何可扩展的云分析系统可以与之进行比较。

大多数人没有那么多数据

“大数据即将到来”图表的预期要点是，很快，每个人都会被他们的数据淹没。十年过去了，那个未来还没有实现。我们可以通过几种方式验证这一点：查看数据（定量），询问人们它是否与他们的经验一致（定性），并从第一原则（归纳）思考它。

当我在 BigQuery 工作时，我花了很多时间研究客户规模。这里的实际数据非常敏感，所以我不能直接分享任何数字。但是，我可以说绝大多数客户的总数据存储量不到 1 TB。当然，也有拥有大量数据的客户，但大多数组织，甚至一些相当大的企业，数据量都适中。

客户数据大小服从幂律分布。最大客户的存储量是第二大客户的两倍，第二大客户的存储量是第一大客户的一半，依此类推。因此，虽然有客户拥有数百 PB 的数据，但大小很快就会下降。有成千上万的客户每月支付不到 10 美元的存储费用，即 0.5TB。在大量使用该服务的客户中，数据存储大小的中位数远低于 100 GB。

在与行业分析师（Gartner、Forrester 等）交谈时，我们发现了对此的进一步支持。我们会称赞我们处理海量数据集的能力，而他们会耸耸肩。“这很好，”他们说，“但绝大多数企业的数据仓库都小于 1 TB。” 我们从业内人士那里得到的普遍反馈是，100 GB 是数据仓库的正确数量级。这是我们在基准测试中集中精力的地方。

我们的一位投资者决定找出分析数据的真实规模，并调查了他的投资组合公司，其中一些公司是退出后的（要么已经首次公开募股，要么被更大的组织收购）。这些是科技公司，它们可能会倾向于更大的数据量。他发现他投资组合中最大的 B2B 公司拥有大约 1TB 的数据，而最大的 B2C 公司拥有大约 10TB 的数据。然而，大多数人的数据要少得多。

为了理解为什么大数据很少见，思考数据的实际来源是有帮助的。假设您是一家中型企业，拥有 1000 名客户。假设您的每位客户每天都会下一个包含一百个订单项的新订单。这是相对频繁的，但它仍然可能少于每天生成的 1 M字节数据。三年后你仍然只有 1 GB，而要产生 1 TB 则需要几千年。

或者，假设您的营销数据库中有 100 万条线索，并且您正在开展数十个活动。您的线索表可能仍然不到 1 GB，并且跟踪每个活动中的每个线索可能仍然只有几 GB。在合理的扩展假设下，很难看出这如何增加海量数据集。

举个具体的例子，我2020-2022年在SingleStore工作，当时是一家快速成长的E轮公司，收入可观，估值独角兽。如果将我们的财务数据仓库、客户数据、营销活动跟踪和服务日志的大小加起来，可能只有几 GB。无论怎么想，这都不是大数据。

存储和计算分离中的存储偏差

现代云数据平台都将存储和计算分开，这意味着客户不受单一外形因素的束缚。这不仅仅是横向扩展，可能是过去 20 年数据架构中最重要的单一变化。与在现实世界条件下难以管理的“无共享”架构不同，共享磁盘架构让您可以独立增加存储和计算。可扩展且速度相当快的对象存储（如 S3 和 GCS）的兴起意味着您可以放宽对如何构建数据库的许多限制。

实际上，数据大小的增长速度远快于计算大小。虽然对存储和计算分离的好处的流行描述听起来好像您可以随时选择扩展其中一个，但这两个轴并不完全等同。对这一点的误解导致了很多关于大数据的讨论，因为处理大计算需求的技术不同于处理大数据的技术。探索为什么会出现这种情况很有帮助。

所有的大数据集都是随着时间的推移而产生的。时间几乎总是数据集中的一个轴。每天都有新订单进来。新的出租车。新的日志记录。正在玩新游戏。如果业务是静态的，既不增长也不收缩，数据将随时间线性增长。这对分析需求意味着什么？显然，数据存储需求将线性增加，除非您决定修剪数据（稍后会详细介绍）。但随着时间的推移，计算需求可能不需要改变太多；大多数分析都是针对最近的数据进行的。扫描旧数据非常浪费；它不会改变，那你为什么要花钱一遍又一遍地看呢？诚然，您可能希望保留它以防万一您想对数据提出新问题，但构建包含重要答案的聚合非常简单。

很多时候，当数据仓库客户从他们没有存储和计算分离的环境转移到他们拥有分离的环境时，他们的存储使用量会大幅增长，但他们的计算需求往往不会真正改变。在 BigQuery 中，我们有一个客户是世界上最大的零售商之一。他们有一个本地数据仓库，大约有 100 TB 的数据。当他们迁移到云端时，他们最终拥有 30 PB 的数据，增加了 300 倍。如果他们的计算需求也增加了类似的数量，他们就会在分析上花费数十亿美元。相反，他们只花了这笔钱的一小部分。

这种对存储大小而不是计算大小的偏见对系统架构产生了实际影响。这意味着如果您使用可扩展的对象存储，您可能能够使用比预期少得多的计算。您甚至可能根本不需要使用分布式处理。

工作负载大小小于整体数据大小

为分析工作负载处理的数据量几乎肯定比您想象的要少。例如，仪表板通常是根据聚合数据构建的。人们查看过去一小时、最后一天或上周的数据。较小的表往往会被更频繁地查询，而大表则更有选择性。

几年前，我对 BigQuery 查询进行了分析，查看了每年花费超过 1000 美元的客户。90% 的查询处理的数据少于 100 MB。我以多种不同的方式对此进行了切片，以确保不仅仅是几个客户运行了大量查询来扭曲结果。我还删除了纯元数据查询，它们是 BigQuery 中根本不需要读取任何数据的查询的一小部分。在进入千M字节之前，您必须在百分位数范围内走得相当高，而且在 TB 范围内运行的查询非常少。

数据量巨大的客户几乎从不查询海量数据

数据量适中的客户通常会进行相当大的查询，但数据量巨大的客户几乎从不查询大量数据。当他们这样做时，通常是因为他们正在生成报告，而性能并不是真正的优先事项。一家大型社交媒体公司会在周末发布报告，为周一早上的高管做准备；这些查询非常庞大，但它们只是他们在本周余下时间运行的数十万个查询中的一小部分。

即使在查询巨型表时，您也很少需要处理大量数据。现代分析数据库可以进行列投影以仅读取字段的子集，并进行分区修剪以仅读取较窄的日期范围。他们通常可以通过分段消除更进一步，通过聚类或自动微分区来利用数据中的局部性。压缩数据计算、投影和谓词下推等其他技巧是您可以在查询时减少 IO 的方法。更少的 IO 转化为需要完成的更少计算，从而转化为更低的成本和延迟。

巨大的经济压力促使人们减少他们处理的数据量。仅仅因为您可以非常快速地横向扩展和处理某些东西并不意味着您可以以低廉的成本做到这一点。如果您使用一千个节点来获得结果，那可能会让您付出沉重的代价。我曾经在舞台上运行以炫耀 BigQuery 的 PB 查询零售价为 5,000 美元。很少有人愿意运行如此昂贵的东西。

请注意，即使您没有使用按扫描字节数付费的定价模型，处理较少数据的经济动机也适用。如果你有一个 Snowflake 实例，如果你可以让你的查询更小，你可以使用一个更小的实例，并且支付更少。您的查询会更快，您可以并发运行更多，而且随着时间的推移，您通常会支付更少的费用。

大多数数据很少被查询

得到处理的数据中有很大一部分不到 24 小时。到数据保存一周时，查询的可能性可能比最近一天低 20 倍。一个月后，数据大多就在那里。历史数据往往很少被查询，也许当有人正在运行一个罕见的报告时。

数据存储时代模式要扁平得多。虽然很多数据很快被丢弃，但很多数据只是附加到表的末尾。最近一年可能只有 30% 的数据，但 99% 的数据访问。最近一个月可能有 5% 的数据，但有 80% 的数据访问。

数据的静止意味着数据工作集大小比您预期的更易于管理。如果您有一个包含 10 年数据的 PB 表，您可能很少访问任何早于当天的数据，这些数据可能压缩了不到 50 GB。

大数据前沿不断后退

“大数据”的一个定义是“任何不适合单台机器的东西……根据这个定义，符合条件的工作负载数量每年都在减少。

在 2004 年撰写 Google MapReduce 论文时，数据工作负载不适合单个商品机器的情况非常普遍。扩大规模是昂贵的。2006 年，AWS 推出了 EC2，您可以获得的实例大小只有单核和 2 GB 内存。有很多工作负载不适合那台机器。

然而，今天，AWS 上的标准实例使用具有 64 个内核和 256 GB RAM 的物理服务器。这是两个数量级的 RAM。如果您愿意为内存优化实例多花一点钱，您可以获得另外两个数量级的 RAM。有多少工作负载需要超过 24TB 的 RAM 或 445 个 CPU 内核？

过去，更大的机器要贵得多。然而，在云中，使用整个服务器的 VM 的成本仅比使用 8 分之一服务器的 VM 高 8 倍。成本随着计算能力线性增加，直到达到一些非常大的规模。事实上，如果您查看使用 3,000 个并行节点在原始 dremel 论文中发布的基准测试，您现在可以在单个节点上获得类似的性能（稍后会详细介绍）。

数据是一种责任

大数据的另一种定义是“当保存数据的成本低于弄清楚要丢弃什么的成本时”。我喜欢这个定义，因为它概括了为什么人们最终会得到大数据。这不是因为他们需要它；而是因为他们需要它。他们只是懒得删除它。如果你想想组织收集的许多数据湖，它们完全符合这个要求：巨大、凌乱的沼泽，没有人真正知道它们拥有什么，也不知道清理它们是否安全。

保存数据的成本高于存储物理字节的成本。根据 GDPR 和 CCPA 等法规，您需要跟踪某些类型数据的所有使用情况。有些数据需要在一定时间内删除。如果您的 parquet 文件中的电话号码在您的数据湖中的某处停留时间过长，则您可能违反了法定要求。

除了监管之外，数据还可以帮助您提起诉讼。正如许多组织实施有限的电子邮件保留政策以减少潜在责任一样，您数据仓库中的数据同样可能被用来对付您。如果您有五年前的日志，这些日志会显示您的代码中存在安全漏洞或错过了 SLA，那么保留旧数据可能会延长您的法律风险。我听说过一个可能是杜撰的故事，说一家公司将其数据分析能力保密，以防止它们在法律发现过程中被使用。

当代码没有得到积极维护时，它经常会出现人们所说的“位腐烂”。数据可能会遇到相同类型的问题；也就是说，人们忘记了专业领域的确切含义，或者过去的数据问题可能已经从记忆中消失了。例如，可能存在将每个客户 ID 设置为空的短暂数据错误。或者有一个巨大的欺诈交易让 2017 年第三季度看起来比实际情况要好得多。从历史时间段提取数据的业务逻辑通常会变得越来越复杂。例如，可能有这样的规则：“如果日期早于 2019 年，则使用 revenue 字段，2019 年至 2021 年之间使用 revenue_usd 字段，2022 年之后使用 revenue_usd_audited 字段。” 您保存数据的时间越长，就越难跟踪这些特殊情况。并非所有这些都可以轻松解决，尤其是在缺少数据的情况下。

如果您要保留旧数据，最好了解为什么要保留它。你是否一遍又一遍地问同样的问题？如果是这样的话，就存储和查询成本而言，仅存储聚合是否会便宜得多？你把它留着以备不时之需吗？您是否认为您可能想提出新的问题？如果是这样，它有多重要？您真正需要它的可能性有多大？你真的只是一个数据囤积者吗？这些都是要问的重要问题，尤其是当您试图计算出保留数据的真实成本时。

你是大数据的百分之一吗？

大数据是真实存在的，但大多数人可能不需要担心。您可以提出一些问题来确定您是否是“大数据 One-Percenter”：

• • 您真的会生成大量数据吗？

• • 如果是这样，您真的需要一次使用大量数据吗？

• • 如果是这样，数据真的太大而无法放在一台机器上吗？

• • 如果是这样，你确定你不仅仅是一个数据囤积者吗？

• • 如果是这样，您确定总结一下会更好吗？

如果您对这些问题中的任何一个回答“否”，那么您可能是新一代数据工具的理想人选，这些工具可以帮助您以实际拥有的规模处理数据，而不是人们试图恐吓您以为您有一天可能拥有的规模。